Для тех из вас, кто по каким-либо причинам еще не обновился на vSphere 5.5, полезная новость - вышло обновление VMware vSphere 5.1 Update 3 (ESXi и vCenter), которое уже доступно для загрузки. Новых возможностей не появилось, зато была добавлена поддержка новых гостевых ОС и исправлены некоторые значимые баги.

Итак, что нового в ESXi и vCenter 5.1 U3:

• Поддержка новых БД vCenter Server - теперь можно использовать Oracle 12c и Microsoft SQL Server 2014
• Поддержка новых браузеров для Web Client 5.1 Update 3. Теперь поддерживаются:
  • Internet Explorer 8 / 9 / 10/ 11
  • Firefox 31 / 32 / 33
  • Google Chrome 36 / 37
• Поддержка новых гостевых ОС. Полный список поддерживаемых ОС можно посмотреть тут.
• Множественные исправления ошибок. Полный список тут. Самое главное - пофикшен баг с некорректным бэкапом после увеличения дисков.

Ссылки на загрузку :

• VMware vCenter Server 5.1.0 Update 3
• VMware ESXi 5.1 Update 3

Кроме того, был также обновлен и кастомизированный образ для серверов HP. Его можно скачать по этой ссылке - ESXi 5.1 Update 3 HP Customized.

Новые возможности кастомизированного образа:

• Поддержка серверов Gen9 HP ProLiant
• Утилита HP CONREP Utility, которая позволяет сохранить аппаратную конфигурацию сервера и распространить ее на другие системы
• Поддержка Smart Array HBA mode
• Поддержка новых контроллеров HP Smart Array
• Поддержка новых HP Smart HBA
• Поддержка памяти DDR4
• Поддержка технологии SR-IOV (вот тут список поддерживаемых адаптеров и драйверов)

Для VMware vSphere 5.5 тоже на днях вышел небольшой багофикс.

Компания StarWind Software, известная своими продуктами для создания отказоустойчивых программных хранилищ под VMware vSphere и Microsoft Hyper-V, объявляет о начале промо-акции для новых клиентов - "покупайте сейчас - платите позже".

Согласно условиям предложения, вы получаете возможность на срок до 90 дней отсрочить платеж по подписанному счету за лицензии на любые издания StarWind Virtual SAN.

Кроме того, на данные продукты действует еще одно беспрецедентное предложение - 30-дневный манибэк в случае, если что-то в продукте вас не устроит (без каких-либо вопросов).

Для того, чтобы воспользоваться данным предложением, нужно заполнить форму вот по этой ссылке, или направьте письмо на этот адрес - sales@starwindsoftware.com.

На прошедшей конференции VMworld Europe 2014 компания VMware объявила о скором выпуске решения VMware Horizon FLEX, представляющего собой платформу виртуализации для настольных ПК, позволяющую запускать виртуальные ПК локально (как на Mac, так и в Windows), без требования связи с датацентром компании.

Как вы знаете в прошлом у VMware были такие продукты, как VMware ACE и VMware View Local Mode, которые ушли в прошлое, а теперь на замену им приходит технология FLEX.

VMware Horizon FLEX - это не какой-то отдельный продукт, это комбинированная технология на базе трех решений:

• Horizon FLEX Policy Server - это центральный сервер управления виртуальными ПК, он отвечает за назначение политик и управление ими.
• Horizon FLEX Clients - это рабочие места пользователей с установленными на них Fusion Pro или Player Pro (то есть, уже знакомые вам продукты). Перед началом использования решения пользователь скачивает виртуальную машину целиком с сервера, после чего может работать с ней локально.
• Mirage for Horizon FLEX - продукт для управления компонентами виртуального десктопа (система, приложения, данные).

На сервере FLEX Policy Server администратор датацентра назначает виртуальной машине политики, такие как срок использования этого ПК, доступность USB-устройств, средства обмена с хостовой ОС и другое. В этом смысле продукт похож на решение VMware ACE (если тут кто его еще помнит).

С этого сервера можно управлять виртуальными ПК пользователей, например, машину можно просто залочить в любой момент:

Интересный момент заключается в том, что несмотря на то, что решение называется Horizon FLEX, установка Horizon View или VMware vSphere вовсе не обязательна. Ну и поскольку все исполняется локально вам не нужно дополнительных хранилищ для хранения этих виртуальных ПК. При этом машину можно размещать как на диске ноутбука, так и на отдельной флешке.

Один из вариантов применения этого продукта - концепция BYOD, например, когда у человека собственный удобный Мак, на котором он хочет работать, а корпоративные стандарты предписывают иметь винду. Тогда он может использовать Windows-машину как рабочую с помощью решения FLEX.

Вот какие политики присутствуют в Horizon FLEX:

• Устаревание всей ВМ (Time limit).
• Время использования в офлайн-режиме (без соединения с сервером).
• Частота обновления политик.
• Доступ к USB-устройствам.
• Состояние механизмов копирования данных (операции drag-and-drop, copy-and-paste).
• Ограниченный доступ к настройкам виртуальной машины (чтобы пользователь не лазил куда-попало).

На данный момент для Horizon FLEX поддерживаются следующие хостовые ОС:

• Windows XP SP3, Windows Vista, Windows 7, Windows 8 (помните, что Player Pro поддерживает только 64-битные ОС).
• Mac OS X 10.8 или более поздняя, Mac OS X 10.9 или более поздняя, Mac OS X 10.10 или более поздняя.

Гостевые ОС те же, за исключением того, что можно использовать их 32-битные версии.

Типовая схема рабочего процесса администратора Horizon FLEX:

Типовая схема рабочего процесса пользователя VMware Horizon Flex:

Скачать VMware Horizon Flex можно по этой ссылке, а почитать интересные документы о продукте можно тут и тут.

Как знают многие администраторы VMware vSphere, в инфраструктуре хранилищ иногда возникает проблема выравнивания виртуальных дисков машин (последний раз мы писали об этом тут). Некорректное выравнивание блоков может возникать на двух уровнях - гостевой ОС по отношению к VMFS и VMFS по отношению к блокам дискового массива:

В целом-то, эта проблема не очень актуальна в последнее время, учитывая что в последних версиях VMware vSphere и ОС Windows с этим вполне разобрались. Однако для тех, у кого инфраструктура очень древняя (особенно с ВМ на базе Windows 2003 и 2008), пережила несколько апгрейдов и миграций - выравнивание блоков проверить было бы нелишним.

Именно для этого и была выпущена бесплатная утилита VM Check Alignment. Утилита старенькая, но вполне себе работает для Windows 2003/2008 и Windows Vista/7:

В параметре Starting Offset мы видим, что виртуальный диск выровнен корректно, и никаких изменений не требуется. Для некорректно выровненных дисков, кстати, производительность хранилищ может падать на величину до 10%.

О том, как нужно выравнивать блоки виртуальных дисков написано тут и тут.

Скачать VM Check Alignment можно по этой ссылке.

Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), в начале декбря проведет три интересных вебинара:

Building The Highly Available Hyper-V Cluster on Free Microsoft Hyper-V Server - Practice

На этом вебинаре вы узнаете о том, как построить недорогой и эффективный кластер Failover Cluster на базе хранилищ StarWind, а также как можно управлять этим кластером с помощью средств компании 5nine.

Бонус: участники вебинара получают шанс выиграть NFR-лицензию StarWind на 6 месяцев использования.

Вебинар пройдет 3 декабря в 19-00 по московскому времени. РЕГИСТРАЦИЯ.

How to build Microsoft Scale-Out File Server without SAS JBODs

На этом вебинаре Макс Коломейцев, менеджер по продукту Virtual SAN, расскажет о том, как можно построить масштабируемый файл-сервер без применения массивов SAS JBOD, используя возможности протокола SMB 3.0.

Вебинар пройдет 9 декабря в 20-00 по московскому времени. РЕГИСТРАЦИЯ.

Fighting the "I/O Blender" Effect in Virtual Environments

В рамках данного вебинара будет рассказано о том, каким образом можно побороть эффект I/O Blender в виртуальных окружениях (он заключается в том, что запросы ввода-вывода от виртуальных машин "смешиваются" на хост сервере перед направлением к хранилищу). Должно быть очень интересно.

Бонус: участники вебинара получают шанс выиграть NFR-лицензию StarWind на 6 месяцев использования.

Вебинар пройдет 11 декабря в 22-00 по московскому времени. РЕГИСТРАЦИЯ.

Компания VMware выпустила еще один интересный документ, описывающий референсную архитектуру программно-определяемого датацентра (SDDC) - "Creating a VMware Software-Defined Data Center".

В данном документе на 29 страницах приводится пример создания корпоративной инфраструктуры на базе следующих продуктов:

• vCloud Suite Enterprise (подробнее тут)
• VMware vSphere
• VMware NSX (подробнее тут)
• VMware IT Business Management
• VMware vCenter Log Insight (подробнее тут)

Документ состоит из нескольких основных секций:

• Описание программных компонентов для построения SDDC-инфраструктуры
• Обзор референсной архитектуры
• Информация об оборудовании и аппаратных компонентах
• Детальная информация о компонентах Software-Defined Data Center
• Высокоуровневая конфигурация инфраструктуры SDDC

В рассматриваемой архитектуре есть три основных модуля:

• Management Cluster - основной кластер управления и мониторинга, в котором работают такие средства как vCenter, Log Insight и прочие. Состоит минимум из трех хост-серверов ESXi.
• Edge Cluster - отдельный кластер для управления сетевым взаимодействием. Он упрощает конфигурацию физической сети передачи данных путем создания абстракции физического сетевого стека в ИТ-инфраструктуре. Также содержит минимально 3 хоста.
• Payload Cluster - "рабочая лошадка" виртуальной инфраструктуры, кластер, где крутятся рабочие нагрузки. Может масштабироваться "подами" (pods) по мере роста потребностей предприятия.

В целом документ весьма интересный, так как в комплексе затрагивает управляющие компоненты виртуальной инфраструктуры и показывает работу средств управления большой виртуальной средой, а также то, каким образом эти средства решают возникающие в такой инфраструктуре проблемы.

Некоторое время назад мы писали заметку о том, "Почему снапшоты виртуальных машин в VMware vSphere - это плохо", да и вообще часто затрагиваем эту тему.

Ниже мы приведем еще один аргумент в пользу того, чтобы не создавать снапшоты виртуальных машин на постоянной основе (во временном их использовании нет ничего плохого).

Итак, в одной из статей мы писали про расширенную настройку VMFS Heap Size (размер кучи), которая косвенно определяет максимально доступный объем хранилищ на хосте.

Также мы писали о том, что параметр VMFS3.MaxHeapSizeMB еще в VMware vSphere 5.1 был увеличен до 640 МБ.

Однако есть и куча для механизма "Copy-on-Write" (COW), которая определяется расширенной настройкой COW.COWMaxHeapSizeMB - она ограничивает число одновременно запущенных на хосте виртуальных машин. Механизм COW работает на хосте, когда у машины есть снапшоты (дельта-диски).

По умолчанию это значение равно 192 МБ, но может быть увеличено до 256 МБ:

Также этот параметр можно узнать из командной строки:

~ # esxcfg-advcfg -g /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 192

И установить его в максимальное значение:

~ # esxcfg-advcfg -s 256 /COW/COWMaxHeapSizeMB
Value of COWMaxHeapSizeMB is 256MB

Давайте посмотрим, как расходуется пространство этой кучи на хосте, в зависимости от параметров виртуальных машин на нем. Вот тут есть такая интересная формула:

X = (75 / 100 * COW_HEAP_SIZE) / ((B / (2 * 1048576) * 4 * S) * Y)

где:

X - это максимальное число запущенных виртуальных машин на хосте,
COW_HEAP_SIZE - размер кучи в байтах,
B - размер виртуального диска в байтах,
2 * 1048576 - это GDE Coverage (хз, что такое),
4 - это число байт на Root Entry,
S - число снапшотов каждого из виртуальных дисков,
Y - число дисков у машин.

Возьмем для примера машину с 5 дисками размером в 80 ГБ по 6 снапшотов у каждого при максимальном размере кучи в 256 МБ. Получим, что таких машин может быть запущено на хосте:

= (75 / 100 * 268435456) / ((85899345920 / (2 * 1048576) * 4 * 6) * 5)

Это примерно около 40 машин (всего лишь) - при максимально доступном размере кучи на VMware ESXi. Понятно дело, что мало где можно найти машины с 5 дисками, у каждого из которых по 6 снапшотов, но я видел подобные конфигурации пару раз.

Нетрудно понять, как в этой формуле влияют снапшоты на максимальное число запущенных виртуальных машин. Поэтому повторим еще раз: постоянные снапшоты - зло.

Многие из вас знают о продукте vGate R2 от компании Код Безопасности, который позволяет защитить виртуальную инфраструктуру предприятия от несанкционированного доступа, а также безопасно настроить ее на базе политик. Напомним, что vGate R2 есть как для VMware vSphere, так и для инфраструктуры Microsoft Hyper-V.

Тем из вас, кому приходится обрабатывать в своей компании персональные данные (ПДн), наверняка знаком приказ ФСТЭК номер 21 "Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных". На него ориентируются менеджеры физических и виртуальных инфраструктур при организации защиты датацентра, где присутствует обработка ПДн.

Надо сказать, что компания Код Безопасности обеспечивает исполнение этого приказа во всех аспектах, но нас больше интересует виртуальная среда. Итак, скачиваем вот этот документ с сайта Кода Безопасности.

Открываем его на первой вкладке и видим необходимые нам категории в столбце "vGate 2.5":

Очень удобно, что все требования разбиты по категориям, а также указано сразу какой уровень защищенности ПДн обеспечивает то или иное средство. Вот какие конкретно требования ФСТЭК по защите персональных данных позволяет выполнить vGate R2:

• Идентификация и аутентификация пользователей, являющихся работниками оператора
• Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных
• Управление идентификаторами, в том числе cоздание, присвоение, уничтожение идентификаторов
• Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации
• Защита обратной связи при вводе аутентификационной информации
• Управление (заведение, активация, блокирование и уничтожение) учетными записями пользователей, в том числе внешних пользователей
• Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа
• Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами
• Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы
• Ограничение неуспешных попыток входа в информационную систему (доступа к информационной системе)
• Разрешение (запрет) действий пользователей, разрешенных до идентификации и аутентификации
• Поддержка и сохранение атрибутов безопасности (меток безопасности), связанных с информацией в процессе ее хранения и обработки
• Обеспечение доверенной загрузки средств вычислительной техники
• Управление запуском (обращениями) компонентов программного обеспечения, в том числе определение запускаемых компонентов, настройка параметров запуска компонентов, контроль за запуском компонентов программного обеспечения
• Определение событий безопасности, подлежащих регистрации, и сроков их хранения
• Сбор, запись и хранение информации о событиях безопасности в течение установленного времени хранения
• Реагирование на сбои при регистрации событий безопасности, в том числе аппаратные и программные ошибки, сбои в механизмах сбора информации и достижение предела или переполнения объема (емкости) памяти
• Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них
• Защита информации о событиях безопасности
• Контроль работоспособности, параметров настройки и правильности функционирования программного обеспечения и средств защиты информации
• Контроль правил генерации и смены паролей пользователей, заведения и удаления учетных записей пользователей, реализации правил разграничения доступа, полномочий пользователей в информационной системе
• Контроль целостности программного обеспечения, включая программное обеспечение средств защиты информации
• Контроль целостности персональных данных, содержащихся в базах данных информационной системы
• Обеспечение возможности восстановления программного обеспечения, включая программное обеспечение средств защиты информации, при возникновении нештатных ситуаций
• Резервирование технических средств, программного обеспечения, каналов передачи информации, средств обеспечения функционирования информационной системы
• Идентификация и аутентификация субъектов доступа и объектов доступа в виртуальной инфраструктуре, в том числе администраторов управления средствами виртуализации
• Управление доступом субъектов доступа к объектам доступа в виртуальной инфраструктуре, в том числе внутри виртуальных машин
• Регистрация событий безопасности в виртуальной инфраструктуре
• Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по периметру виртуальной инфраструктуры
• Доверенная загрузка серверов виртуализации, виртуальной машины (контейнера), серверов управления виртуализацией
• Управление перемещением виртуальных машин (контейнеров) и обрабатываемых на них данных
• Контроль целостности виртуальной инфраструктуры и ее конфигураций
• Разбиение виртуальной инфраструктуры на сегменты (сегментирование виртуальной инфраструктуры) для обработки персональных данных отдельным пользователем и (или) группой пользователей
• Обеспечение доверенных канала, маршрута между администратором, пользователем и средствами защиты информации (функциями безопасности средств защиты информации)
• Обеспечение подлинности сетевых соединений (сеансов взаимодействия), в том числе для защиты от подмены сетевых устройств и сервисов
• Изоляция процессов (выполнение программ) в выделенной области памяти

Да да, все это умеет делать vGate R2. Для того, чтобы узнать о том, как именно он это делает, читайте наши статьи тут и тут.

Кстати, этот эксель-док очень интересен с точки зрения комплексной защиты персональных данных, обрабатываемых в ИТ-инфраструктуре. Посмотрите различные продукты, пощелкайте по вкладкам - там много интересного.

Демо-версию vGate для Hyper-V можно бесплатно скачать по этой ссылке, а для VMware vSphere - по этой.

Те из вас, кто пользуется продуктом VMware vSphere Data Protection (VDP) для репликации данных виртуальных машин знают, что нужно лицензировать только исходные хост-серверы для репликации, а целевые - не нужно. В версии VDP 5.5 для лицензирования целевых хостов использовалась специальная лицензия типа “zero-CPU”, которую надо было добавлять вручную (подробнее - тут):

В версии vSphere Data Protection 5.8 появился новый вариант развертывания - Replication Target, который нужен как раз для того, чтобы на резервной площадке принимать бэкапы, не вводя лицензионный ключ от vSphere Data Protection Advanced. Об этом и рассказывает документ "vSphere Data Protection Replication Target".

Таким образом, при установке VDP можно выбрать один из трех вариантов:

• vSphere Data Protection (VDP) - дефолтный вариант установки, который включает в себя возможности бэкапа и репликации виртуальных машин и файлов только на хранилища EMC Avamar. На другие виртуальные модули в этом варианте реплицировать нельзя. Это издание доступно вместе с VMware vSphere и не требует отдельного ключа установки.
• vSphere Data Protection Advanced (VDP Advanced) - это вариант установки продукта с лицензией, который не требует наличия Avamar. Это уже полноценный продукт для бэкапа и репликации больших объемов данных, поддержка консистентных бэкапов и т.п.
• vSphere Data Protection Replication Target (VDP-RT) - этот вариант нужен, когда виртуальный модуль развертывается только для обслуживания реплик, которые отбрасываются с основного сайта. В этом случае вводить лицензионный ключ не нужно. На этом модуле можно проводить только восстановление данных, а возможности резервного копирования отключены.

Как многие из вас знают, у компании VMware есть бесплатный продукт VMware vSphere Hypervisor, который в народе называется VMware ESXi Free. Многие начинающие администраторы, услышав, что ESXi бесплатен, устанавливают его, но забывают накатить лицензию, которую надо скачивать с портала My VMware. Без этого бесплатный VMware ESXi будет работать в режиме пробной версии 60 дней...

Компания ИТ-ГРАД, ведущий российский провайдер IaaS-инфраструктур на базе VMware vSphere, предлагает нашим читателям бесплатную книгу "IaaS для бизнеса по кирпичикам" об аренде виртуальных машин из облака.

Книга предназначена для тех, кто впервые сталкивается с облаками и понятием IaaS (Infrastructure as a Service).

Книга рассчитана на бизнес-аудиторию, желающую разобраться в последних тенденциях в сфере ИТ.

Книга написана доступным языком, позволяет за 5 минут погрузиться в базовые определения и принципы построения эффективной ИТ-инфраструктуры.

Прочитав данную книгу, вы найдете ответы на следующие вопросы:

• Какие ИТ-сервисы имеет смысл выносить на аутсорсинг?
• Какие сервисы лучше оставить внутри?
• 7 шагов по снижению рисков перехода в облако.
• Как выбрать поставщика облачных услуг и убедиться в его надежности?

Ссылка на скачивание книги придет вам на электронную почту после заполнения формы.

Как установить IP-параметры HP iLO через консоль сервера VMware ESXi.

При развертывании инфраструктуры VMware vSphere на базе серверов HP всегда требуется задать параметры IP-идентификации для интерфейса удаленной консоли iLO. Обычно это делается в настройках сервера, но удобнее сделать это из консоли ESXi, если вы используете кастомизированную сборку ESXi под HP (а ее надо использовать, так как некоторые девайсы могут просто не работать, поскольку в стандартной сборке под них нет драйверов).

Для начала откроем на хосте ESXi доступ по SSH в разделе Security Profile, стартовав соответствующий сервис:

Заходим на хост по SSH и переходим в папку с утилитами HP:

cd /opt/hp/tools

Копируем настройки HP iLO в файл XML:

./hponcfg -w ilo.xml

Далее этот файл нам нужно отредактировать, для этого можно использовать WinSCP или Veeam FastSCP.

Копируем iLO.xml к себе локально:

Открываем его в текстовом редакторе и правим секции, помеченные красным:

<!-- HPONCFG VERSION = "4.0-13.0" -->
<!-- Generated 11/11/2014 23:37:47 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<DIR_INFO MODE="write">
<MOD_DIR_CONFIG>
<DIR_AUTHENTICATION_ENABLED VALUE = "N"/>
<DIR_LOCAL_USER_ACCT VALUE = "Y"/>
<DIR_SERVER_ADDRESS VALUE = ""/>
<DIR_SERVER_PORT VALUE = "636"/>
<DIR_OBJECT_DN VALUE = ""/>
<DIR_OBJECT_PASSWORD VALUE = ""/>
<DIR_USER_CONTEXT_1 VALUE = ""/>
<DIR_USER_CONTEXT_2 VALUE = ""/>
<DIR_USER_CONTEXT_3 VALUE = ""/>
</MOD_DIR_CONFIG>
</DIR_INFO>
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "100"/>
<FULL_DUPLEX VALUE = "N"/>
<IP_ADDRESS VALUE = "192.168.16.33"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.16.254"/>
<DNS_NAME VALUE = "ESX01-iLO"/>
<PRIM_DNS_SERVER value = "192.168.16.1"/>
<DHCP_ENABLE VALUE = "N"/>
<DOMAIN_NAME VALUE = "educ.local"/>
<DHCP_GATEWAY VALUE = "Y"/>
<DHCP_DNS_SERVER VALUE = "Y"/>
<DHCP_STATIC_ROUTE VALUE = "Y"/>
<DHCP_WINS_SERVER VALUE = "Y"/>
<REG_WINS_SERVER VALUE = "Y"/>
<PRIM_WINS_SERVER value = "0.0.0.0"/>
<STATIC_ROUTE_1 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_2 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
<STATIC_ROUTE_3 DEST = "0.0.0.0" GATEWAY = "0.0.0.0"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
<USER_INFO MODE="write">
</USER_INFO>
</LOGIN>
</RIBCL>

Копируем измененный файл обратно на хост ESXi (предыдущий сохраните - просто переименуйте) и выполняем команду заливки конфигурации:

./hponcfg -f ILO.xml

Дождитесь успешного выполнения команды - и можно коннектиться к iLO через веб-браузер по новому адресу. Этот способ удобен тем, что можно не перезагружать сервер.

Многие пользователи VMware Virtual SAN (VSAN), когда проводят тест бэкапа одной виртуальной машины, замечают, что время резервного копирования этой ВМ существенно больше, чем таковое для машины, размещенной на дисковом массиве.

Дункан в своем блоге подробно разбирает эту проблему. Тут дело вот в чем - когда вы используете дисковый массив, то виртуальная машина "размазывается" по дискам RAID-группы, что позволяет читать одновременно с нескольких дисков. Это дает хорошую производительность операции резервного копирования для одной машины.

Кластер же VSAN работает немного по-другому. Это объектное хранилище, в котором виртуальный диск ВМ хранится на одном хосте и его реплика существует на втором. Кроме этого, есть кэш на SSD-диске (но его еще нужно "прогреть"). То есть выглядит все это следующим образом:

Соответственно, при бэкапе одной виртуальной машины данные читаются только с двух HDD-дисков, а не с нескольких как в традиционной архитектуре дисковых массивов, при этом сам кластер VSAN может состоять из нескольких хостов (до 32 узлов). То есть, это архитектурное ограничение.

Однако если мы будем делать одновременный бэкап нескольких виртуальных машин с хранилища Virtual SAN время этой операции уже будет сравнимо с дисковым массивом, поскольку будет задействовано сразу несколько дисков на каждом из хостов, плюс хорошо прогреется кэш. Поэтому проведение такого теста (ведь он ближе к реальным условиям) и было бы более показательным при сравнении Virtual SAN и традиционных хранилищ.

То же самое относится и к VDI-инфраструктуре на базе VSAN - многие пользователи отмечают, что первая фаза операции Recompose (когда создается реплика - полный клон ВМ) отрабатывает весьма медленно. Однако если вы делаете много таких операций - кэш прогревается, и одновременное создание нескольких клонов начинает работать заметно быстрее в расчете на одну машину.

Мы довольно часто пишем про продукт номер 1 для защиты виртуальных инфраструктур VMware и Microsoft - vGate R2. Напомним, что недавно мы рассказали о настройке решения vGate R2 для Hyper-V, которое вышло несколько месяцев назад, но уже обладает очень мощным функционалом.

Кроме того, не стоит забывать и о версии vGate R2 для защиты виртуальных инфраструктур на платформе VMware vSphere, которая выпускается уже много лет и была доступна еще для VMware ESX 3.x.

С тех пор очень многое изменилось, продукт используется во множестве крупных российских компаний для обеспечения защиты от несанкционированного доступа, а также приведения инфраструктуры в соответствие отраслевым стандартам и лучшим практикам средствами политик.

Поэтому для вашего удобства компания Код Безопасности сделала табличку со списком измнений vGate от версии к версии (информация актуальна для коммерческих релизов).

Например в vGate R2 релиз 2.7 появились следующие новые возможности:

• Обеспечена поддержка работы vSphere 5.5 Web-client.
• Добавлен шаблон настроек для нового стандарта VMware Security Hardening Guide 5.5.
• Обеспечена поддержка сценария развертывания сервера авторизации в виртуальной машине.
• Добавлены новые возможности в консоль управления, обеспечивающие:
  - древовидное отображение списка виртуальных машин;
  - более удобную настройку правил доступа;
  - оптимизацию работы за счет возможности отключения контроля уровня сессий пользователей;
  - установку компонента защиты vCenter из консоли управления vGate

Скачать пробную версию vGate R2 можно по этой ссылке, а за информацией о продукте заходите сюда. Продукт также можно купить онлайн здесь.

Многие пользователи в целях безопасности хотят отключить использование USB-портов на хостах VMware ESXi - а то кто-нибудь зайдет в серверную комнату и утащит данные на диске.

К сожалению, на текущих версиях платформы VMware vSphere сделать этого нельзя. Можно, конечно, отключить USB Arbitrator service следующей командой (как написано вот тут):

/etc/init.d/usbarbitrator stop

Но это лишь отключит проброс USB-устройств в виртуальные машины, при этом само устройство (например,  /dev/usb0101) отключено не будет. Поэтому, тут остается два решения:

• Отключить USB-устройства в BIOS - но это поддерживают не все производители железа.
• Мониторить использование локальных USB-устройств и слать алерты менеджеру по ИБ.

Второй вариант можно реализовать с помощью продукта VMware vRealize Log Insight, который позволяет мониторить логи хостов ESXi и слать по ним алерты при их появлении и повторении. Вот, например, в выводе этого лога мы видим, что кто-то подключал USB-девайс к хосту:

Сопоставив время этих событий и время посещения конкретными людьми датацентра, мы поймем, кто пытался или сделал что-то нехорошее. Решение, конечно, не ахти, но какое уж есть.

На сайте компании VMware есть полезная утилита vSphere Replication Calculator, которая позволяет рассчитать целевые параметры репликации в зависимости от следующих факторов:

• Наличие у вас Network-based storage
• Число виртуальных машин и объем виртуальных дисков - как следствие размер реплицируемых данных (Size of dataset)
• Интенсивность изменения данных (Data change rate)
• Требования к контрольной точке восстановления (Recovery point objective, RPO)
• Имеющийся канал на резервную площадку (Link speed)

В качестве результата расчетов можно выбрать одно из трех представлений (все зависит от значения поля "Are you trying to solve..."):

• Необходимая минимальная пропускная способность сети на резервную площадку (recommended minimum throughput) с приемлемой latency (настраивается как входной параметр).
• Рекомендуемое минимальное время RPO в качестве политики, выражающей требования к контрольной точке восстановления.
• Максимальное число реплицируемых виртуальных машин при условии заданного объема изменяющихся данных.

Получившийся отчет можно сохранить в PDF.

Бывают такие ситуации, когда у вас в руках только мобильный телефон, с которого возникает необходимость перезагрузить виртуальную машину на хосте VMware ESXi. Например, у вас в инфраструктуре что-то случилось, но вы имеете доступ к ней через VPN со своего айфона.

Если у вас есть доступ по SSH, то проблему решить весьма просто, как это описано вот тут (а также в KB 1014165). Скачиваем бесплатное приложение Server Auditor по этой ссылке (если у вас андроид - то по этой).

Далее заходим на свой хост ESXi по SSH и выполняем команду:

esxcli vm process list

Будет выведен список всех процессов виртуальных машин, где нам нужно найти World ID нужной машины. Записываем или запоминаем его.

Далее убиваем виртуальную машину командой (вместо параметра force можно использовать hard и soft для выключения ВМ):

esxcli vm process kill -t force -w WorldID

Выглядит это примерно вот так:

Далее снова выполняем команду esxcli vm process list, чтобы убедиться, что виртуальная машина теперь выключена.

Теперь запоминаем VMID нашей виртуальной машины, который можно получить с помощью команды:

vim-cmd vmsvc/getallvms

Если помните часть имени ВМ, можно искать с помощью grep:

vim-cmd vmsvc/getallvms |grep <текст в имени ВМ>

Найдя VMID, проверяем дополнительно, что она выключена:

vim-cmd vmsvc/power.getstate <vmid>

Теперь включаем виртуальную машину:

vim-cmd vmsvc/power.on <vmid>

Вот и все, потом обязательно нужно проверить, что машина включилась, естественно - сначала в списке процессов, а потом пингом.

Как стало известно из VMware KB 2090639, в гипервизоре VMware vSphere 4.x и всех более поздних версий (включая vSphere 5.5) есть серьезный баг - оказывается, при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT), если их результирующий размер перешагивает 128 ГБ (а также 256, 512, 1024 и т.д.) - их резервные копии оказываются невалидными и не подлежащими восстановлению.

Напомним, что Changed Block Tracking - это техника, которая работает на уровне стека работы с хранилищами в модуле VMkernel и позволяет сторонним продуктам для резервного копирования вернуть список изменившихся блоков с момента последнего бэкапа. Технику CBT используют практически все решения для резервного копирования виртуальных машин, в частности Veeam Backup and Replication.

Сама же ошибка в VMware vSphere связана с тем, что функция QueryChangedDiskAreas, возвращающая информацию об изменившихся дисковых секторах, может выдавать некорректное или вообще пустое значение. Таким образом, если вы восстановите инкрементальный бэкап такой машины, то он работать не будет.

Еще раз отметим, что риску подвержены только те виртуальные машины, размер виртуальных дисков был увеличен до величины строго большей 128 ГБ (а также 256, 512 и т.п. - то есть "перешагнул" границу). Иными словами, если вы со 100 ГБ увеличили диск до 120 ГБ - ошибки не будет, а вот если со 120 ГБ до 130 ГБ - ошибка уже появится.

На данный момент исправления для этой проблемы, потенциально затрагивающей практически всех пользователей VMware vSphere (так как баг есть и в 4.x, и в 5.x), не существует. В качестве костыля можно отключить CBT на всех виртуальных машинах и включить его снова - тогда баг должен уйти.

Сделать это можно через скрипт PowerCLI.

Получаем список всех виртуальных машин с включенной CBT:

$vms=get-vm | ?{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

Создаем спецификацию для наложения нужной настройки (CBT - отключена):

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.ChangeTrackingEnabled = $false

Применяем спецификацию к каждой виртуальной машине, затем создаем и удаляем снапшот:

foreach($vm in $vms){
$vm.ExtensionData.ReconfigVM($spec)
$snap=$vm | New-Snapshot -Name 'Disable CBT'
$snap | Remove-Snapshot -confirm:$false}

Проверяем, остались ли машины со включенной CBT:

get-vm | ?{$_.ExtensionData.Config.ChangeTrackingEnabled -eq $true}

Для того, чтобы включить CBT обратно, в спецификации указываем $spec.ChangeTrackingEnabled = $true и повторяем процедуру.

Как всегда, первой подсуетилась компания Veeam и главный по продукту - Антон Гостев.

Как убедиться в том, что инфраструктура облачного провайдера действительно не имеет единой точки отказа? Проверить это на деле!

В этой заметке сотрудники ИТ-ГРАД расскажут о том, как они проводили приёмо-сдаточные испытания своей новой облачной площадки.

Предыстория

24 сентября мы открыли новую публичную облачную площадку в Санкт-Петербурге. Вот тут предварительный план испытаний облачной платформы.

И вот мы приступаем…

Удаленное тестирование

1. Поочередное выключение контроллеров FAS8040

Ожидаемый результат... [Читать статью далее]

Компания StarWind, поставщик ПО номер 1 для создания отказоустойчивых кластеров хранилищ в инфраструктурах VMware vSphere и Microsoft Hyper-V (о возможностях продукта - тут), спешит анонсировать свои ноябрьские вебинары.

Занесите даты себе в календарь:

6 ноября в 17-00 по московскому времени

Бесплатный вебинар "How to Reduce Disaster Recovery Expenses up to 50% - DR & BC Best Practices for Virtual Environments".

На вебинаре будут рассмотрены следующие темы:

• Бизнес-потребности в решениях для непрерывности бизнеса и восстановления после сбоев (BC/DR).
• Чем решения BC/DR отличаются от простой аппаратной отказоустойчивости.
• Стратегии для внедрения BC/DR на основе вида приложения и целевого уровня сервиса (Service Level Objectives).
• Выбор между решениями для восстановления средствами дискового массива и средствами гипервизора.
• Выбор между решениями для восстановления на уровне ВМ и на уровне LUN.
• Технические решения для отказоустойчивости виртуальных серверов, включая Microsoft Hyper-V, VMware vSphere и платформы с открытым исходным кодом.
• Сторонние решения для восстановления виртуальных сред.

РЕГИСТРАЦИЯ

Бесплатный вебинар "Building a Highly Available Hyper-V Cluster Using Free Microsoft Hyper-V Server"

На вебинаре будут рассмотрены следующие темы:

• Достоинства кластера высокой доступности Hyper-V failover cluster
• Упрощение управления кластером и виртуальными машинами средствами 5nine Manager for Hyper-V
• Сокращение затрат, увеличение надежности и минимизация оборудования за счет StarWind Virtual SAN
• Удовлетворение потребностей виртуальной среды за счет расширения и масштабирования решения

РЕГИСТРАЦИЯ

16 ноября в 23-00 по московскому времени

Бесплатный вебинар "Reduce Disaster Recovery & Business Continuity Expenses with Windows Server Clustering and Geo-Clustering"

На вебинаре будут рассмотрены следующие темы:

• Требования технологии Windows Failover Clustering.
• Рекомендации по кворумным дискам, сетевому окружению и хранилищам.
• Геокластеризация для восстановления после сбоев.
• Использование StarWind Virtual SAN для многоузловых и просто масштабируемых кластеров

РЕГИСТРАЦИЯ

Некоторое время назад мы писали про средство управления инстансами в облаке Amazon для платформы VMware vSphere - AWS Management Portal for vCenter, которое позволяет управлять виртуальными машинами, находящимися в облаке EC2 прямо из консоли vCenter, при этом доступен достаточно обширный набор возможностей.

На днях похожее (только намного более куцее) средство Amazon выпустила и для инфраструктур на базе ПО Microsoft - AWS Systems Manager for Microsoft System Center Virtual Machine Manager.

Данное средство от Amazon позволяет отслеживать список инстансов в облаке EC2 (по регионам и зонам доступности), проводить с ними опреации start/stop/reset и соединяться с консолью нужного инстанса по RDP.

Плагин AWS Systems Manager для SC VMM доступен совершенно бесплатно. Его можно использовать для Microsoft SC VMM 2012 SP1 и более поздних версий. Скачать плагин можно по этой ссылке.

Кстати, кроме этого плагина к SC VMM компания Amazon также предоставляет Management Pack для использования в System Center Operations Manager (для версий 2007 R2 и 2012/2012 R2). Отличия его от вышеупомянутого средства в том, что Management Pack для Operations Manager используется для мониторинга и репортинга по окружению EC2 (в том числе, о производительности), а Systems Manager для SC VMM предназначен, в первую очередь, для операций с виртуальными машинами (запуск/останов/доступ к консоли).

Любители постеров уже давненько не видели чего-то нового от VMware. Но вот очередной постер прибыл - VMware vSphere PowerCLI 5.8 Release 1 Reference Poster. Там, как всегда, вы найдете список командлетов и примеры их применения с учетом последней версии интерфейса к PowerShell - PowerCLI 5.8 Release 1.

Некоторое время назад мы писали о технологии VMware vFlash (она же Virtual Flash), которая позволяет использовать высокопроизводительные накопители SSD (вот тут - о производительности) для решения двух важных задач:

• Предоставление виртуальным машинам дополнительного места, в которое будут свопиться страницы памяти в случае недостатка ресурсов на хосте (это намного более производительно, чем свопить на обычный HDD-диск). Эта техника называется Virtual Flash Host Swap и пришла на смену механизму Swap to SSD.
• Прозрачное встраивание в поток ввода-вывода на хосте между виртуальными машинами и хранилищами, что позволяет существенно ускорить операции чтения данных виртуальных дисков. Называется это VMware Flash Read Cache (vFRC).

Ниже мы вкратце расскажем о настройке этих двух механизмов через VMware vSphere Web Client (в обычном C#-клиенте этого, к сожалению, нет). Если что, более подробно о технике vFRC можно почитать по этой ссылке.

Итак, в vSphere Web Client переходим на вкладку "Manage" для нужного хоста, далее в разделе "Settings" выбираем пункт "Virtual Flash Resource Management". Это кэш, который мы добавляем для того, чтобы в случае нехватки места, его могли использовать виртуальные машины, чтобы не свопить данные на медленный магнитный диск, кроме того он же будет использоваться для целей vFRC.

Нажимаем Add Capacity:

Выбираем диски, которые мы будем использовать как Host Swap и нажимаем "Ок" (все данные на них будут стерты):

Всего под нужды Virtual Flash может быть выделено до 8 дисков суммарной емкостью до 32 ТБ. Видим, что ресурс добавлен как Virtual Flash Resource (его емкость отдельно учитывается для vFRC и Host Cache):

Настройка Virtual Flash Host Swap

Первым делом рекомендуется настроить именно этот кэш, а остаток уже распределять по виртуальным машинам для vFRC.

Выбираем пункт "Virtual Flash Host Swap Cache Configuration" в левом меню, а далее в правой части мы нажимаем кнопку "Edit":

Указываем необходимый объем, который планируется использовать, и нажимаем "Ок":

После того, как мы настроили нужное значение - в случае недостатка ресурсов на хосте виртуальные машины будут использовать высокоскоростные диски SDD для своих нужд внутри гостевой ОС (файлы подкачки прочее).

Настройка VMware Flash Read Cache (vFRC)

Напомним, что это кэш только на чтение данных, операции записи будут производиться на диск, минуя флэш-накопители. Соответственно, такой кэш улучшает производительность только операций чтения.

Сам кэш vFRC можно настроить на уровне отдельных виртуальных машин на хосте VMware ESXi, а также на уровне отдельных виртуальных дисков VMDK.

Чтобы выставить использование нужного объема vFRC для отдельной виртуальной машины, нужно выбрать пункт "Edit Settings" из контекстного меню ВМ и на вкладке "Virtual Hardware" в разделе "Virtual Flash Read Cache" установить нужное значение для соответствующего виртуального диска:

Если этого пункта у вас нет, то значит у вас версия виртуального "железа" (Virtual Machine Hardware) ниже, чем 10, и ее нужно обновить.

По ссылке "Advanced" можно настроить размер блока для кэша (значение Reservation, установленное тут, обновит значение на предыдущем скрине):

Чтобы понять, какие значения SSD-кэша можно и нужно выставлять для виртуальных машин, рекомендуется почитать документ "Performance of vSphere Flash Read Cache in VMware vSphere 5.5".

30 октября компания Код Безопасности проводит бесплатный вебинар "Виртуализация: доступ к данным под контролем", посвященный особенностям защиты виртуальных инфраструктур в соответствии с требованиями регуляторов и новым возможностям продукта vGate R2. Вебинар проведет Яков Хамаганов, эксперт по технологиям защиты информации компании "Код Безопасности".

Вебинар пройдет 30 октября 11-00 по московскому времени. Продолжительность вебинара - 60 минут.

Напомним, что vGate R2 предназначен для защиты виртуальных инфраструктур средствами политик, а также от несанкционированного доступа к элементам инфраструктуры, таким как виртуальные машины, хранилища и сети.

В ходе вебинара Вы узнаете:

• об особенностях защиты информации в виртуальных инфраструктурах VMware vSphere и Microsoft Hyper-V;
• о том, что нового появилось в СЗИ vGate и как с помощью vGate построить надежную систему защиты;
• о том, как сертифицированный vGate поможет выполнить требования приказов №17 и №21 ФСТЭК России по защите персональных данных.

Вебинар будет интересен руководителям служб безопасности и ИТ-директорам, а также специалистам, обеспечивающим безопасность дата-центров и защиту виртуальных инфраструктур.

По окончании вебинара Вы сможете задать докладчику вопросы в режиме чата и оставить заявки на получение демо-версии продукта и дополнительных материалов.

РЕГИСТРАЦИЯ.

Ниже приведем ссылки на статьи VMware Knowledge Base (взято отсюда), где можно узнать о расположении и назначении файлов журнала (логов) для различных продуктов, включая компоненты решения VMware vSphere.

vSphere Suite

vCenter Server:

• Location of vCenter Server log files (1021804)
• Location of vCenter Inventory Service log files (2056632)
• Location of vSphere Profile-Driven Storage log files (2056646)
• Location of vCenter Single Sign-On log files for vCenter Server 5.1 and 5.5 (2033430)
• Collecting diagnostic information for the vSphere Client or VMware Infrastructure Client (1003687)
• Location of vSphere Web Client service logs (2004090)
• Locating logs for VMware vSphere Update Manager 5.0 (2038036)
  

ESX(i):

• Location of vSphere ESXi Dump Collector log files (2003277)
• Location of ESX 3.0-4.1 log files (1021800)
• Location of ESXi 3.5-4.1 log files (1021801)
• Location of ESXi 5.0 log files (2004201)
• Location of ESXi 5.1 and 5.5 log files (2032076)

vSphere Data Recovery:

• Location of VMware Data Recovery (VDR) log files (1022680)

vSphere Storage Appliance:

• Location of vSphere Storage Appliance log files (2003547)

Site Recovery Manager

• Location of Site Recovery Manager log files (1021802)

vCloud Suite

vCloud Director:

• Location of vCloud Director log files (2021435)
• Overview of Lab Manager log files (1011478)

vShield/vCloud Networking and Security (vCNS):

• Overview of vShield logs (1026255)
• Obtaining logs and information needed for VMware vShield products (2012760)

VMware vCloud Automation Center 6.x:

• Log locations in VMware vCloud 6.x Suite (2074803)

vCenter Orchestrator:

• Location of vCenter Orchestrator log files (1010956)

Desktop Computing

View and Horizon View:

• Location of VMware View log files (1027744)

Horizon Mirage (formerly Mirage):

• Location of VMware Horizon Mirage log files (2046069)

VMware Workstation:

• Collecting diagnostic information for VMware Workstation (1346)

Те из вас, кто следит за анонсами VMware VMworld 2014, которые были сделаны в Штатах, а затем в Европе, наверняка слышали о такой штуке как VMware Project Fargo (его прежнее название - VM Fork), которая позволяет очень быстро сделать работающую копию работающей виртуальной машины на платформе VMware vSphere.

Суть технологии VMFork такова, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory), что и родительская ВМ. При этом дочерняя ВМ в шаренную память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:

Обратите внимание, что дочерняя ВМ появляется на свет без изначальной загрузки.

В процессе работы VMFork происходит кратковременное "подвешивание" родительской ВМ (quiescence) с помощью технологии "fast suspend resume" (FSR), после чего дочерняя ВМ "отцепляется" от родительской. При этом ВМ шарят общие ресурсы на чтение и имеют свои уникальные области на запись - это очень удешевляет стоимость ресурсов в перерасчете на одну ВМ на хосте.

Все это позволяет создать так называемый Just-in-time desktop, который создается до 30 раз быстрее, чем обычный, и "отпочковывается" от родителя по запросу пользователя. Не исключено, что данная технология заменит текущие механизмы связанных клонов в VMware View Composer.

За механизм шаринга общих страниц памяти будет отвечать уже существующая техника Transparent Page Sharing, которую отключат для обычных ВМ в следующих релизах, но она будет продолжать трудиться на благо VMFork.

Очевидно, что применений у такой технологии очень много - от мгновенного создания десктопов по требованию для продуктивной VDI-среды (не надо понапрасну загружать ресурсы "теплыми" десктопами) до тестовых окружений, где разработчик или тестировщик могут мгновенно создать себе рабочее окружение для различных проверок и тестов.

Кстати, помните мы писали про решение CloudVolumes, которое позволяет распространять виртуализованные приложения VMware ThinApp в виде дисков VMDK, которые можно подцепить к виртуальным машинам, предоставляя тем самым ее пользователям доступ к данному приложению?

Так вот если объединить Project Fargo (VM Fork) и CloudVolumes, то получится решение по почти мгновенному развертыванию рабочей среды пользователя со всеми необходимыми приложениями. Это решение внутри VMware называется Project Meteor.

Все эти штуки - VMFork и Project Meteor мы, возможно, увидим в обновленной версии платформы виртуализации VMware vSphere 6.0, которая выйдет в следующем году.

Четыре с половиной года назад мы писали про то, что у технологии Transparent Page Sharing (TPS), которая по-умолчанию используется в VMware vSphere, нет будущего. Напомним, что TPS - это механизм поиска и удаления дубликатов страниц памяти в целях экономии физического пространства RAM (вместо самой дублирующейся страницы хранится ссылка на нее).

Технолония потеряла актуальность, когда вовсю стали применяться большие страницы памяти (Large Memory Pages), для которых размер страницы равен 2 МБ, а значит вероятность появления двух полностью одинаковых страниц очень низка.

Ну вот и пришло время эту технологию отключать. На днях компания VMware выпустила статью базы знаний "Security considerations and disallowing inter-Virtual Machine Transparent Page Sharing", в которой заявляется о том, что в будущих релизах платформы виртуализации VMware vSphere функции TPS будут по умолчанию отключены (хотя и доступны).

Это во многом связано с тем, что TPS (помимо негативного влияния на производительность хоста) - это еще и потенциальный источник проблем, связанных с неавторизованным доступом к данным оперативной памяти. Эти моменты основаны на аналитическом исследовании, выводы из которого опубликованы в статье базы знаний "Additional Transparent Page Sharing management capabilities in ESXi 5.5 patch October 16, 2014 and ESXi 5.1 and 5.0 patches in Q4, 2014 (2091682)".

Вот когда TPS будет отключен в VMware vSphere:

• ESXi 5.5 Update release – Q1 2015
• ESXi 5.1 Update release – Q4 2014
• ESXi 5.0 Update release – Q1 2015
• VMware ESX 6.x и более поздние версии

Более подробно о проблемах с TPS написано вот в этой статье на блогах VMware.

Если же вы хотите отключить этот механизм уже прямо сейчас, то нужно сделать следующее:

1. Залогиниться на ESX\ESXi или vCenter Server через vSphere Client.
2. Выбрать нужный хост и зайти на вкладку Configuration, затем перейти в Advanced Settings в секции Software.
3. Выбираем раздел Mem и в нем устанавливаем значение параметра Mem.ShareScanGHz в 0.

После патча и обновлений ESXi механизм TPS можно будет включить следующим образом (Advanced Settings в секции Software):

• Параметр Mem.ShareForceSalting (включение TPS на уровне всего хоста ESXi). Если значение стоит 0 - то значит TPS по-прежнему работает на хосте, если 1 - механизм отключен.
• Параметр sched.mem.pshare.salt (ставится на уровне ВМ) позволяет включать/отключать TPS для отдельных виртуальных машин (например, старые Windows или линуксы - для них можно было бы включить). Когда параметр ShareForceSalting установлен в значение 1, то для нуждающихся в TPS машин в их Advanced Configuration нужно установить одинаковые значения "соли". Без этого TPS не работает - соответственно, он отключен.

На проходящей сейчас в Барселоне конференции VMware VMworld Europe 2014 компания VMware сделала немало интересных анонсов. Один из них - анонс VMware vRealize Operation Management Suite 6.0 (vROPS), который объединяет в себе несколько продуктов, которые теперь будут известны под новыми именами.

Напомним, что о vRealize Suite мы уже писали вот тут, когда проходил VMworld 2014 в штатах. Суть ренейминга продуктов заключается в следующем:

А точнее:

• vRealize Suite - это комплект продуктов vCAC + vCenter Operations Suite + Log Insight + ITBM
• vRealize Operations (он же бывший vCenter Oerations Suite)
• vRealize Operations Manager (он же vCenter Operations)
  vRealize Operartions Insight (аддон VSOM, продукт vRealize Operations + Log Insight).

Также будут добавлены еще два новых продукта:

• vRealize CodeStream 1.0 - доставка кода приложений в продакшен.
• vRealize Air Compliance (Beta) - возможность проверки виртуальной производственной среды на соответствие нормативным документам и отраслевым стандартам (например, VMware vSphere Security Hardening).

По-сути, комплект продуктов vRealize Suite 6.0 представляет собой платформу для управления гибридным облаком на решениях VMware (а именно, частная инфраструктура VMware vSphere + публичное облако VMware vCloud Air).

С помощью vRealize предполагается управлять не только гибридным облаком от VMware, но также и другими лидирующими на рынке публичными облаками (например, виртуальными машинами в облаке Amazon EC2).

Кроме того, с помощью компонентов vRealize предполагается также управлять и физическими системами:

Новые возможности и улучшения комплекта vROPS 6.0:

• Улучшены возможности развертывания отдельной установки на площадке.
• Поддержка работы компонентов в режиме кластера - общие данные и интерфейс пользователя.
• Режим Resiliency (так называемый RAID из приложений).
• Умные алерты (smart alerts) с возможностью получить детальную информацию о проблемах, которые могут произойти.
• Кастомизабельные дэшборды и отчеты (можно править их посредством drug and drop).
• Улучшения модели расчета необходимых дисковых емкостей для растущей инфраструктуры, с возможностями по сохранению данных расчетов и выполнения моделирования по схеме "что-если?".
• Публичный API, доступный партнерам VMware.
• Возможность интеграции management packs, которые доступны на VMware Solution Exchange (всего около 40-50 штук для разных приложений).

Решения vROPS развертываются в виде виртуальных модулей, между которыми создается кластер. Узлы в нем называются слайсами (slices):

Есть специальная консоль, где можно наблюдать за жизнедеятельностью узлов:

При первом развертывании решений пакета вам предлагается ответить на несколько вопросов мастера, который развернет компоненты решения в зависимости от вашего выбора:

На дэшбордах можно увидеть основные проблемы жизнедеятельности датацентра, потенциальные риски и какие-то метрики эффективности:

При клике на алерт вам предлагают вариант решения:

Также можно использовать заранее подготовленные сценарии для устранения проблем определенного типа.

Если проблему сходу не решить, то можно использовать решение VMware Log Insight для проведения более глубокого анализа (то есть, "ковыряния в логах"):

Если проблема повторится, то вы уже будете видеть ее описание и решите ее мгновенно.

Каждое представление может быть преобразовано в отчет:

Можно также создавать кастомные отчеты:

VMware vRealize Suite 6.0 доступен в двух изданиях:

• Advanced ($5750 за CPU сервера)
• Enterprise ($9950 за CPU)

VMware vRealize Operations Insight также лицензируется отдельно по процессорам (цена начинается от $2000 за CPU). Все указанные цены - американские, у нас будет значительно дороже.

Доступность и стоимость VMware vRealize Air Automation пока еще не раскрывается, но на бета-тест можно подписаться вот тут: http://vrealizeair.vmware.com.

Часто пользователям требуется информация о том, какому номеру билда соответствует версия продукта от VMware (такое бывает нужно, например, для VMware vSphere / ESXi, vCenter, vCenter Server Appliance). К тому же, иногда бывает полезно узнать, когда вышла та или иная версия продукта.

Поэтому мы взяли из этого поста информацию о продуках, датах релиза и номерах версий, чтобы можно было всегда обращаться к этому посту у нас.

Converter Standalone / Enterprise

Нажимайте читать далее.